01 MCP基础与架构

MCP（Model Context Protocol）是一个用于连接AI应用和外部系统的开放协议。它的目标不是定义模型如何推理，也不是替代Function Calling，而是为工具、数据源和提示词模板提供一套标准接入方式。

在AI Agent项目中，MCP通常承担“标准接口层”的角色。外部系统可以被封装成MCP Server，Agent所在的应用通过MCP Client连接这些Server，再把可用能力提供给模型使用。

一、MCP解决的问题

没有MCP时，Agent接入外部系统通常需要单独写适配代码：

Agent -> 数据库SDK
Agent -> GitHub API
Agent -> 文件系统API
Agent -> 内部业务HTTP接口

这种方式会带来几个问题：

问题	说明
接入方式分散	每个系统都有自己的认证、参数、错误处理和调用方式
工具复用困难	同一个工具往往需要为不同Agent或不同客户端重复适配
上下文标准不统一	文件、数据库记录、提示词模板等上下文缺少统一描述方式
安全边界分散	权限、确认、审计容易散落在各个工具实现中

MCP把外部能力标准化为协议对象，使AI应用可以通过统一方式发现、读取和调用这些能力：

MCP Host
  └── MCP Client
        └── MCP Server
              ├── Tools
              ├── Resources
              └── Prompts

二、核心参与方

MCP采用客户端-服务端架构，核心参与方包括Host、Client和Server。

参与方	作用
MCP Host	用户直接使用的AI应用，例如桌面助手、IDE插件、Agent平台
MCP Client	Host内部的连接组件，负责和某个MCP Server建立会话
MCP Server	能力提供方，负责把外部系统包装成MCP能力

一个Host可以连接多个MCP Server。通常每连接一个Server，Host内部都会创建一个对应的MCP Client，并维护一条独立连接。

AI应用（Host）
├── MCP Client A -> 文件系统 MCP Server
├── MCP Client B -> 数据库 MCP Server
└── MCP Client C -> GitHub MCP Server

其中，MCP Server既可以运行在本机，也可以运行在远程服务上。本地Server常使用stdio传输，远程Server常使用Streamable HTTP传输。

三、协议分层

MCP可以分成两层理解：数据层和传输层。

层级	作用
数据层	定义JSON-RPC消息、生命周期、能力协商、Tools、Resources、Prompts等协议语义
传输层	定义消息如何在Client和Server之间传递，例如stdio和Streamable HTTP

数据层使用JSON-RPC 2.0作为基础消息格式。传输层负责把这些JSON-RPC消息送到对端。

这种分层的好处是：同一套MCP语义可以运行在不同传输方式上。本地开发时可以用stdio，生产环境中也可以通过HTTP暴露远程MCP Server。

四、Server暴露的三类能力

MCP Server主要向Client暴露三类能力：Tools、Resources和Prompts。

能力	定位	典型场景	控制方
Tools	可执行动作	查询数据库、调用API、修改文件、创建工单	模型发起调用，应用可做确认
Resources	可读取上下文	文件内容、数据库schema、文档页面、API响应	应用选择是否加入上下文
Prompts	可复用提示词模板	代码审查模板、总结模板、业务流程模板	用户或应用显式选择

三者的差异很重要：

• Tools强调“执行动作”，可能产生副作用。
• Resources强调“提供上下文”，通常是只读信息。
• Prompts强调“复用任务模板”，帮助用户或Host组织标准流程。

五、一次典型调用流程

一次MCP工具调用通常包含以下步骤：

1. Host创建MCP Client，并连接MCP Server。
2. Client发送initialize请求，完成协议版本和能力协商。
3. Server返回自身能力，例如是否支持tools、resources、prompts。
4. Client通过tools/list、resources/list、prompts/list发现可用能力。
5. Host把可用工具描述提供给模型或应用层。
6. 模型决定调用某个工具。
7. Client发送tools/call请求到Server。
8. Server执行真实逻辑并返回结果。
9. Host把结果交给模型继续生成回答。

对应关系可以表示为：

用户请求
  ↓
Host将可用工具提供给模型
  ↓
模型选择工具和参数
  ↓
MCP Client -> tools/call -> MCP Server
  ↓
Server执行外部系统操作
  ↓
结果返回给模型

六、MCP和Function Calling的关系

MCP和Function Calling经常一起出现，但它们关注的层次不同。

对比项	Function Calling	MCP
关注点	模型如何输出结构化工具调用	外部工具如何被标准化发现和执行
所在层	模型能力或应用编排层	工具接入协议层
解决问题	让模型选择函数名和参数	让AI应用统一连接工具、资源和提示词
典型输出	函数名、参数JSON	JSON-RPC请求、工具列表、资源内容、调用结果

在实际系统中，两者通常配合使用：模型通过Function Calling决定调用哪个工具，应用再通过MCP Client把调用转发给对应的MCP Server。

七、使用边界

MCP适合标准化AI应用和外部系统之间的连接，但它不负责以下内容：

• 不定义LLM如何推理。
• 不替代Agent编排框架。
• 不强制规定Host的UI形态。
• 不自动解决权限、审计和业务安全问题。
• 不要求底层业务系统放弃原有API。

在企业系统中，MCP更常见的定位是：保留原有数据库、HTTP API、SDK和内部服务，在其上封装一层面向AI应用的标准协议接口。

八、总结

MCP的核心价值是把外部能力标准化，让AI应用可以统一发现和调用工具、读取上下文、复用提示词模板。

概念	作用
Host	承载用户交互的AI应用
Client	Host内部负责连接Server的组件
Server	对外暴露工具、资源、提示词的程序
Tools	可执行动作
Resources	可读取上下文
Prompts	可复用任务模板
Transport	Client和Server之间的通信方式

理解这些概念后，后续开发MCP Server时就可以把重点放在“如何把已有系统能力包装成标准MCP能力”上。